Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@app/src/main/java/com/threegap/bitnagil/navigation/home/HomeNavigator.kt`:
- Around line 33-37: The current navigateTo(route: HomeRoute) uses
navController.navigate(route) with popUpTo(0) which clears the entire back stack
and prevents per-tab state preservation; replace that behavior by navigating
with a popUpTo targeting the nav graph's start destination (use
navController.graph.findStartDestination().id) and enable saveState = true
inside the popUpTo block, add launchSingleTop = true on the navigate options,
and set restoreState = true so each Bottom Navigation tab preserves and restores
its own back stack and UI state instead of wiping it on every tab switch.

In
`@data/src/main/java/com/threegap/bitnagil/data/routine/datasource/RoutineLocalDataSource.kt`:
- Around line 9-13: clearCache currently only resets the in-memory schedule but
leaves lastFetchRange set, causing stale range-based cache hits; update
RoutineLocalDataSourceImpl.clearCache() so it also sets lastFetchRange = null
when you reset _routineSchedule (i.e., clear both the schedule and the
lastFetchRange fields in the clearCache implementation to maintain cache
consistency).

In
`@data/src/main/java/com/threegap/bitnagil/data/routine/datasourceImpl/RoutineLocalDataSourceImpl.kt`:
- Around line 16-22: lastFetchRange is a single mutable var causing cache
inconsistency when multiple collectors (e.g., HomeViewModel and
RoutineListViewModel) call observeWeeklyRoutines with different ranges; change
the shared single-range cache to a range-keyed cache or per-consumer tracking:
replace lastFetchRange and the single _routineSchedule state usage in
RoutineLocalDataSourceImpl with a Map<Pair<String,String>, RoutineSchedule> (or
track ranges per-collector ID) and update saveSchedule, refreshCache, and
observeWeeklyRoutines to read/write by the specific range key so concurrent
observers don’t overwrite each other’s cached ranges and data.

In
`@data/src/main/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImpl.kt`:
- Around line 84-96: The rollback uses routineLocalDataSource.lastFetchRange
which can differ from the week that dateKey refers to; update
flushPendingChanges to compute or retrieve the correct rollback range for the
given dateKey instead of relying on lastFetchRange — e.g., calculate the week
range from dateKey (or maintain a map like originalFetchRangeByDate keyed by
dateKey when optimistic updates are created) and call fetchAndSave(rangeStart,
rangeEnd) with that range; ensure the code paths around pendingChangesByDate,
originalStatesByDate and the onFailure handler use that computed/retrieved range
to rollback the exact week for the dateKey.
- Around line 39-44: The mutableMapOf instances pendingChangesByDate and
originalStatesByDate in RoutineRepositoryImpl are not thread-safe and are
concurrently accessed by applyRoutineToggle (called from multiple ViewModels)
and flushPendingChanges (running on repositoryScope); replace them with
thread-safe structures or add synchronization: either change both to
ConcurrentHashMap<String, ConcurrentHashMap<String, RoutineCompletionInfo>>
(ensure inner maps are concurrent too) or introduce a Mutex used to wrap every
read/write/iteration in applyRoutineToggle and flushPendingChanges so all
accesses are protected; update any code that iterates or updates nested maps to
use thread-safe patterns (e.g., computeIfAbsent on concurrent maps or withLock
on the Mutex) to avoid ConcurrentModificationException and data loss.
- Around line 55-65: The current observeWeeklyRoutines flow mutates a single
shared routineLocalDataSource.lastFetchRange and calls
clearCache()/fetchAndSave(startDate, endDate), causing cache thrashing when
multiple subscribers request different ranges; change observeWeeklyRoutines to
provide per-range isolation by keying flows by (startDate,endDate) instead of
using the single lastFetchRange: introduce a map (e.g.,
MutableMap<Pair<String,String>, StateFlow<RoutineSchedule?>> or SharedFlow)
inside RoutineRepositoryImpl that returns or creates a dedicated flow per range,
call fetchAndSave(range) and update only that range's state (or have
routineLocalDataSource expose per-range storage/fetch methods), and remove
dependence on routineLocalDataSource.lastFetchRange/clearCache so concurrent
subscribers for different ranges do not clobber each other.

In
`@domain/src/main/java/com/threegap/bitnagil/domain/routine/usecase/ApplyRoutineToggleUseCase.kt`:
- Around line 12-17: ApplyRoutineToggleUseCase.invoke currently trusts
UI-snapshot params (isCompleted, subRoutineCompletionStates) which can be stale;
move the toggle calculation into the data layer so the final state is derived
from the source-of-truth atomically. Change ApplyRoutineToggleUseCase.invoke to
pass only identity (dateKey, routineId) and the toggle intent/strategy to
RoutineLocalDataSource (or a new method on it), and implement an atomic
read-modify-write in RoutineLocalDataSource that reads the latest completion
state, computes the new isCompleted and subRoutineCompletionStates (including
the sub-routine toggling logic), persists the result, and returns the updated
state; remove reliance on the passed snapshot params from
ApplyRoutineToggleUseCase and ensure callers send only the minimal intent.

In
`@presentation/src/main/java/com/threegap/bitnagil/presentation/screen/routinelist/RoutineListViewModel.kt`:
- Around line 73-82: The observeWeeklyRoutines function is missing the
repeatOnSubscription wrapper and error handling; wrap the flow collection inside
repeatOnSubscription { ... } (same pattern as HomeViewModel) and add a .catch {
e -> reduce { state.copy(isLoading = false) /* optionally log or signal error */
} } before collect so exceptions don't propagate and loading state is cleared;
update references in the block to observeWeeklyRoutinesUseCase(...) and the
existing reduce calls (state.copy(...)) accordingly.

---

Nitpick comments:
In
`@data/src/main/java/com/threegap/bitnagil/data/routine/datasourceImpl/RoutineLocalDataSourceImpl.kt`:
- Around line 54-56: The clearCache() implementation only nulls _routineSchedule
but leaves lastFetchRange stale; update RoutineLocalDataSourceImpl.clearCache to
also reset the fetch-range state (e.g., set lastFetchRange to null or its
initial value) at the same time you call _routineSchedule.update so the cache
and its range metadata stay consistent; reference the symbols clearCache,
_routineSchedule, and lastFetchRange and perform the reset using the same
concurrency-safe/state-updating mechanism used for _routineSchedule.

In
`@presentation/src/main/java/com/threegap/bitnagil/presentation/screen/routinelist/RoutineListViewModel.kt`:
- Around line 38-41: The init block in RoutineListViewModel starts work
immediately (calling updateDate(selectedDate) and observeWeeklyRoutines()) and
can begin collecting flows before the container is subscribed; move that
initialization into the container's onCreate callback so it is lifecycle-aware:
remove the init block and call updateDate(selectedDate) and
observeWeeklyRoutines() from container(onCreate = { ... }) inside
RoutineListViewModel (mirror the pattern used in HomeViewModel) to ensure flows
are collected only after the container is created.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@core/designsystem/src/main/java/com/threegap/bitnagil/designsystem/component/block/BitnagilConfirmDialog.kt`:
- Around line 24-39: The BitnagilConfirmDialog currently forwards onConfirm to
BasicAlertDialog's onDismissRequest which causes dismiss actions (back
press/outside touch) to trigger confirm; add a new parameter onDismiss: () ->
Unit (defaulting to empty or a no-op) to BitnagilConfirmDialog and pass
onDismiss to BasicAlertDialog's onDismissRequest while keeping onConfirm for the
confirm button handler (e.g., the existing onConfirm lambda used only for the
positive action). Update function signature (BitnagilConfirmDialog) and internal
call sites to use onDismissRequest = onDismiss and ensure any callers are
adjusted or rely on the default no-op to preserve backwards compatibility.

In
`@data/src/main/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImpl.kt`:
- Around line 74-77: fetchAndSave currently throws exceptions (throw it) which
terminates flows and breaks Result<Unit> contracts; change fetchAndSave to
return Result<Unit> (or Result<...> as appropriate) instead of throwing, use
Result.success on success and Result.failure on failures, and remove direct
throw; update all callers—observeWeeklyRoutines, refreshCache,
flushAllPendingChanges and the .also invocations inside
deleteRoutine/registerRoutine/editRoutine/deleteRoutineForDay—to explicitly
handle the Result (log or emit an error state, convert to a failed Result<Unit>
for caller APIs, and avoid rethrowing) so the debounce collector and retry logic
aren’t interrupted and Result<Unit> APIs preserve their contract.

---

Duplicate comments:
In
`@data/src/main/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImpl.kt`:
- Around line 62-71: Current implementation uses a single shared lastFetchRange
and routineSchedule so clearCache() and null emissions affect all collectors;
change to a range-keyed cache/flow: replace
routineLocalDataSource.lastFetchRange and routineLocalDataSource.routineSchedule
with a Map<Pair<String,String>, RoutineSchedule?> (and/or a Map to
StateFlow<RoutineSchedule?>) keyed by (startDate to endDate), update
observeWeeklyRoutines to look up or create the per-range StateFlow for the given
key (do not call global clearCache()), call a per-key clear or refresh only for
that key, and ensure fetchAndSave(startDate, endDate) writes the result into the
map entry/StateFlow for that key so multiple collectors can subscribe to
different weeks without stomping each other.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@data/src/main/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImpl.kt`:
- Around line 147-150: The current refreshCache() call swallows the Result from
fetchAndSave(), so write operations
(deleteRoutine/deleteRoutineForDay/registerRoutine/editRoutine) can report
success while the subsequent refetch fails and leaves local SSOT stale or
overwrites optimistic changes; update those callers to propagate fetchAndSave()
failures (i.e., await and return a failure Result when fetchAndSave fails) or,
alternatively, modify refreshCache()/fetchAndSave() to reapply pending
optimistic changes after a successful sync; specifically locate refreshCache(),
fetchAndSave(), and the write methods
deleteRoutine/deleteRoutineForDay/registerRoutine/editRoutine and either (A)
surface the Result from fetchAndSave() up to the write methods and return an
error when it fails, or (B) have refreshCache() call fetchAndSave(), check its
Result, and on success reapply any pending optimistic toggles before returning
so the local SSOT remains consistent.

---

Duplicate comments:
In
`@data/src/main/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImpl.kt`:
- Around line 64-72: The current implementation uses a single global cache and
lastFetchRange, so concurrent subscriptions for different (startDate,endDate)
ranges overwrite each other; change to a per-range cache/flow and per-range
fetch metadata instead. Replace the single
routineLocalDataSource.routineSchedule / lastFetchRange usage with a map keyed
by Pair(startDate,endDate) (e.g., Map<Pair<String,String>,
MutableStateFlow<RoutineSchedule?>> or store per-range entries inside
RoutineLocalDataSource), update observeWeeklyRoutines to getOrCreate the flow
for the requested range rather than clearing a global cache, have
fetchAndSave(startDate,endDate) write only to that range’s entry, and ensure
rollback restores that specific range’s previous value (not the global
lastFetchRange); update calls to clearCache(), saveSchedule(), lastFetchRange to
operate per-range or remove global clearing to avoid cross-range interference.
- Around line 67-72: 현재 observe flow에서 fetchAndSave(...).getOrThrow()를 사용하면 초기
fetch나 onEach 복구 fetch 실패 시 예외가 throw되어 collector가 종료되므로, getOrThrow() 호출을 제거하고
실패를 예외로 던지지 않도록 변경하세요: 초기 블록과 onEach 블록 모두에서 fetchAndSave(startDate, endDate)를
runCatching/Result 처리하거나 try-catch로 감싸서 실패 시 routine 관찰을 중단시키지 않고 별도의 오류 채널(예:
routineErrorFlow 또는 SharedFlow/Channel)로 에러를 emit하거나 로깅한 뒤 계속 진행하도록 만드세요; 대상 심볼:
fetchAndSave, routineLocalDataSource.routineSchedule, observeWeeklyRoutines
(onEach 처리 부분).

---

Nitpick comments:
In
`@data/src/test/java/com/threegap/bitnagil/data/routine/repositoryImpl/RoutineRepositoryImplTest.kt`:
- Around line 48-80: Add a concurrent-subscription test that verifies
observeWeeklyRoutines handles two simultaneous collectors for different date
ranges without clobbering cache/lastFetchRange: create the repository, set
remoteDataSource.scheduleResponse appropriately for each range, launch two
concurrent collectors (e.g., via runTest + async/launch) that subscribe to
observeWeeklyRoutines("2024-01-01","2024-01-07") and
observeWeeklyRoutines("2024-01-08","2024-01-14") and keep them active long
enough to receive emissions, then assert both collectors received their correct
RoutineSchedule results and that remoteDataSource.fetchCount reflects two
fetches; this ensures lastFetchRange and the single local cache do not overwrite
each other when multiple subscribers are active.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@presentation/src/main/java/com/threegap/bitnagil/presentation/screen/routinelist/RoutineListViewModel.kt`:
- Around line 22-27: Add sync-error observation to RoutineListViewModel: add a
Boolean field showSyncErrorDialog to RoutineListState, implement a private
observeRoutineSyncError() in RoutineListViewModel that calls
observeRoutineSyncErrorUseCase() inside intent { repeatOnSubscription { ... } }
and collects errors to update state (set showSyncErrorDialog = true when an
error is emitted), and invoke observeRoutineSyncError() from the ViewModel
onCreate/init block so sync failures trigger the dialog; ensure you reference
the existing ContainerHost intent/repeatOnSubscription flow and update state via
the same state reducer used elsewhere.
- Around line 76-87: The observeWeeklyRoutines() flow lacks error handling so
exceptions from observeWeeklyRoutinesUseCase (e.g., from
fetchAndSave().getOrThrow()) will cancel the coroutine and leave isLoading=true;
add a .catch { e -> reduce { state.copy(isLoading = false /*, optionally set an
error flag/message */) }; /* log or report e */ } between
observeWeeklyRoutinesUseCase(... ) and .collect { ... } so errors are caught and
the UI state is reset, then continue to .collect to update routines as before.